The Boundary Scan technique (BSCAN) is a standardized method for board tests, that was formally approved in 1990 as industry standard IEEE 1149.1 for Test Access Port (TAP) and Boundary Scan (BSCAN) architectures. Connection tests at board level in the production of complex printed circuit boards (PCBs) are based on this specification. If the test object has its own microprocessor as well as flash-based program memory, a built-In self test can be implemented for example by loading the flash memory via Boundary Scan with the aid of a self-test program. Test results stored in memory can be read out again by Boundary Scan after the ending of the test procedure in this case.
To execute Boundary Scan tests two conditions must be fulfilled: At least a few of the integrated circuits (ICs) on the board must comply with the BSCAN specification. In the testing test vectors will then be used to have the desired test executed by a BSCAN register. In addition the product developers must provide a scan path between the individual ICs which leads from the Test Access Port (TAP) through the ICs back to the TAP where the data is finally scanned. For testing electrical connections Boundary Scan tests represent an excellent alternative to in-circuit tests (ICTs). The costs of performing function testing are low, and because of the increasing miniaturization of integrated semiconductor components the assumption is that the trend towards boundary scan will continue.
IEEE-Standard 1149.1 specifies both the necessary hardware structures and also a suitable form of description of all these characteristics in the form of the Boundary Scan Description Language (BSDL). In this case, this standard is kept so open that by definition of customer-specific registers and corresponding instructions application-specific functions can be implemented without losing compatibility. This is precisely the basic premise on which all conventional procedures for in-system programming (ISP) of integrated ASICs which operate on the basis of Boundary Scan are also based, but to date no standard for this has existed. Nor is there a uniform definition of test vector formats for data interchange contained in IEEE-Standard 1149.1.
Whereas the Boundary Scan method in accordance with IEEE-Standard 1149.1 was previously primarily used as an innovative technology for function testing of integrated circuits or for verification and simulation of hardware fault functions, the most recent developments show further possible applications of this principle. As well as use for test purposes, Boundary Scan will also be used very effectively in the area of what is known as In-System-Programming (ISP) of flash memories as well as Programmable Logic Device (PLD) chips, such as Field-Programmable Gate Arrays (FPGAs) with up to 10,000 logic gates per array or Programmable Logic Arrays (PLAs). In this case the individual control and address inputs of a flash memory will be simulated via the chained BSCAN cells of a BSCAN register assigned to these inputs in such a way that either a read or a write operation will be triggered. As can be seen from the basic diagram shown in FIG. 1, the control, address and data signals of the corresponding BSCAN cells can be recorded and output.
IEEE-Standard 1532 published in January 2001 created for the first time a uniform set of standards for the system architecture and a suitable data format for In-System Configuration (ISC) of programmable integrated ASICs. This Standard describes a series of obligatory and optional programming instructions and corresponding data registers. In principle IEEE Standard 1532 represents an expansion of IEEE Standard 1149.1 specifically tailored to the requirements of programming for standardizing the programming process for programmable logic chips, but is fully compatible with the latter. Since IEEE Standard 1532 related exclusively to programmable logic chips however which feature a JTAG interface and are able to store programming data internally, this standard does not relate to flash memory without a JTAG interface. Basically IEEE Standard 1532 includes the standardization of specific ISC data registers, ISC instructions, BSDL expansions for the description of the ISC features as well as a specific file format.
This means that Standard IEEE 1532 goes far beyond all previous solutions and, on the basis of its innovative character, also allows simultaneous programming of a number of compatible components. By using a series of additional functions, such as the use of special program voltage pins, complianceenable pins and the possibility of defining optional ISC instructions, IEEE 1532 also offers the necessary scope for creating application-specific compatibilities. With IEEE Standard 1532 this basically involves a methodical separation of process information and programming files.
The component information needed for programming is contained in corresponding “BSDL expansions” of a BSDL file. A quite major component from the user's standpoint here is what is known as the “Attribute ISC_Flow”. This implements the basic programming functions such as Delete, Program, Verify etc., in corresponding test sequences. If a number of IEEE-1532-compatible components are to be programmed simultaneously, the programming software must have the capability to virtually merge any number of “Attribute ISC_Flows”. Because of this methodology IEEE Standard 1532 provides the facility for programming PLDs from different manufacturers independent of the process technology (e.g. EEPROM, SRAM or flash-based), their architecture or their voltage level.
The BSDL files must be provided type-specifically by the relevant chip manufacturer. In this regard they are a quite significant part of the delivery scope. By contrast the programming data is created individually by the PLD designer via a corresponding target compiler in the form of a data file. Without going into more detail it should merely be mentioned that this involves ASCII files with a specific syntax so that they can be read and edited. In accordance with this function principle, for each component to be programmed there must be a BDSL file and a data file consistent with it available.
Even if the previously described theory of IEEE Standards 1532 appears to promise much, it is in no way sufficient for the practical success of this Standard. The programming software in particular occupies a key position because of the multiplicity of functions necessary and has a decisive effect on determining the efficiency of the ISC operations.
For simultaneous programming of a number of components the time savings that can be achieved depend on a number of different factors. Particular factors to mention here are the complexity, architecture, technology and clock rate of the component involved. To this extent verifiable quantitative statements also depend on the relevant implementation and application.
With Boundary Scan in particular the continuing development of the software tools plays a decisive role for effective implementation of this trailblazing technology in practice. In conjunction with BSCAN-based on-board programming of flash memories, the prior art in this case is especially the integrated development and programming environment system CASCON™ from GÖPEL electronic GmbH of Jena.
To combine the new programming methods with other BSCAN procedures such as debugging, production tests or flash programming, GÖPEL provides a J-Drive program engine that is included for In-System Configuration (ISC) of a PLD directly in the Boundary Scan software package system CASCON™ and POLARIS™ This J-Drive program Engine accesses configuration data from a BSDL file for configuration of a Test Access Port (TAP) according to IEEE Standard 1149.1 which will be used as a control unit to control the BSCAN cells of the BSCAN register via a program interface. In connection with the available controllers based on USB, PCI, PXI or VXI, this allows cost-optimized multi-mode boundary scan systems to be configured with performance tailored for labor, production and service. This makes it possible for example in production to test with just one device a PLD mounted on a circuit board for manufacturing faults, then to configure the PLD and to load a specific production version of the firmware into an available flash memory.
According to the prior art, flash memories are programmed as a rule with the aid of application-specific integrated circuits (ASICs) which are in a position to configure the flash memory involved even during operation. As a rule these are ASICs which support the JTAG Standard IEEE 1149.1 (cf. FIG. 1: Interface between ASIC-1 and Flash-1). For this purpose an abbreviated BSCAN register is used where necessary, with the aid of which the period required for programming the flash memory can be decisively shortened.
However using this method produces a number of problems: Thus for example for programming a flash memory creation of a program is relatively expensive since the configuration (i.e. the connections between ASIC and Flash memory) is taken from the circuit diagram or from the network list derived from it and the BSDL file of the ASIC must be included. Furthermore simultaneous programming of a number of integrated semiconductor components mounted on the same circuit board is not currently possible. Above and beyond this, with conventional methods burst mode is also not possible since with each write cycle the programming data has to be shifted into the ASIC as well as the addresses and the control bits too as a rule.